(To read this, please use monospace font like 'Courier.'
Converted by TTConverter 1.5, the Mac version METAFONT TrueType fonts have
some problems:
* character #1--#32 and #127 are printable characters.
Mac cannot handle this.
Therefore, I modify (re-map) 'cmap' table of the font. Because char 0 to
char 31 (decimal) characters are repeated at char 128, I assigned them (0-31) to glyph 0 (missing character; space). char 32 of the font is not a space and char
127 of the font has a printable character, so I remap them at char 160 and char
255 and assign char 32 and char 127 with glyph 0.
After this, the converted font seems to work fine on screen and QuickDraw
printer (StyleWriter II), but not on PostScript Pinters (LaserWriter.) The
sympton is the printed characters overlap one another at each line. It sounds
like the space width which the system thought is different from the actual one.
I finally solved the mysterious 'advance width' unmatching problem.
The problem is that Mac's PostScript printer driver (LaserWriter) treats glyf 3
differently. On the Microsoft's TrueType font specifications Appendix C,
there's "Apple's Mapping Requirements and Recommendations". It suggests the
first four glyfs be better
Glyf # Name
---------------------------------------------
0 Missing Character glyf
1 Null
2 CR
3 Space
: :
: :
To get a better cross-platform compatibility, this rule has to be observed.
Unfortunately, the original (Window version) TrueType Metafonts do not follow
it.
Previously, I only used 'cmap' re-mapping technique to assign char0 -- char 32
to glyf 0. This works most of the time, except generating PostScript codes.
For some unknown reasons, the printer driver won't use 'cmap' table to retrieve
char 32's 'advance width' information (in 'hmtx' table), while calculating the
spacing in a line. In a result, no matter what char 32 is mapped to in 'cmap'
table, the printer driver always takes entry 03 (the 4th) in 'hmtx' as the
'advance width' of SPACE. In this TrueType Metafont case, the printer driver
takes the width of 'Capital Theta' as that of SPACE (wider than it should be).
The calculated spacing is that characters overlap one another (because an extra
space will be inserted between characters, and the spaces will be scaled down
to justify the words in a line--the scale-down effect is much larger than it
should be.)
So, my solution is:
make entry 03 of 'hmtx' identical to entry 0
'cmap' entry for char 32 is 03 (however, 'loca' #3 will map
it to the real glyf--glyf 0)
Here's the details:
cmap loca glyf hmtx
#0 ------> #0-+=====> #0 xx (width of SPACE)
: : | +---->#1 :
: : | | +-->#2 :
#32------> #3-+ | | +->#3 xx (width of SPACE)
: : | | | : :
: : | | | : :
#128------> #128-+ | | : : (width of Capital Gamma)
#129------> #129---+ | : : (width of Capital Delta)
#130------> #130-----+ : : (width of Capital Theta)
: : : :
The reason of remapping 'loca' table #128 -- #130 is that they are 'composite
glyf' and they internally (in glyf #128--#130 glyf instructions) map themselves
back to 'loca' #1 -- #3 and loca #3 no longer maps to glyf #3. (To follow
the rule of glyf #0 -- glyf #3, actually 'loca' #0 -- #3)
